Architectural support for socio-technical systems

to support multiple views in the sense of (Kruchten 1995). More specifically Darwin corresponds to a couple of Kruchten’s views: the behavioural view and the service view for the purpose of behavioural analysis and construction, respectively. Each view is an elaboration of the basic structural view (i.e., the skeleton upon which the flesh of behavioural specification is hung). 3.2.3.1 Architectural Levels of Reconfiguration In order to inject dynamic reconfiguration into architectural systems, they need to be causally connected at runtime to the corresponding high-level software architecture specification. In more detail, there are two causally-connected models: an architecturelevel model and a runtime-level model. Dynamic reconfiguration can be applied either through an architectural specification at the architecture level, or through reconfiguration primitives at the runtime level. The main goal of successful reconfiguration abstractions is to endow instance architectures with the capability to manipulate portions of its elements at runtime. These abstractions reside in either of the following architectural levels of abstraction, which can be utilised for the purpose of applying changes: ADL/style level and instance level: • ADL or style level: generic patterns—an example could be a ‘protocol stacking’ style, which defines a basic set of elements and constraints for describing linear compositions of ‘protocol’ components. • Instance level—domain-specific and easy to handle in terms of adding/deleting components and/or connectors. An example of the latter (i.e., instance level) is Wermelinger’s approach to reconfiguration (Wermelinger 1999). This approach provides simple reconfiguration scripts rather than a modelling language with complex construct. Reconfiguration scripts consist of primitive reconfiguration operation e.g. adding/deleting components and/or connectors. However, within the CommUnity framework, reconfigurations modelled using Graph Transformation (Wermelinger, Lopes et al. 2001). Another example of instance level reconfiguration is OpenCom (Coulson, Blair et al. 2004) which uses reflection as mean to query component states and perform ad hoc reconfigurations. ACME is an ADL promoted by (Garlan, Monroe et al. 1997) that exemplifies architecture/style level configuration. Its reconfiguration operations depend on: Chapter 3 Software Architecture from Different Perspectives 41 • Invariants— ensuring system-preserving constraints despite the dynamic insertion/removal of ACME elements. • Extension operator— type extension (extend type at runtime) • representation (local reconfiguration)—allowing re-instantiation of the component with different interfaces • Properties—used to describe how components maybe changed at runtime. The gap between runtime level and ADL level management of reconfigurations has been identified by (Joolia, Batista et al. 2005) who provided a causal connection between the ADL level and the runtime level to support both program and ad hoc reconfigurations. They came up with the Plastik framework, which is a meta-framework that integrates both the ADL level management and runtime level management. Such an integration attempts to address the limitations of depending on one of them in reasoning about architectural reconfiguration. Figure 3.1 Palstik meta-framework (Batista, Joolia et al. 2005) It formally specifies runtime configurations through integration and possesses an architecture configurator for ADL (ACME) and a runtime configurator for reflective component runtime (OpenCOM). Consequently, Plastik allows reconfiguration at multiple architectural levels, which enable considerable flexibility. Both foreseen (i.e. programmed) and unforeseen (i.e. ad hoc) reconfigurations are supported. Issues involved in handling these two types of reconfiguration at both levels and the mapping between them, are Style Level